This disclosure relates to computers and the interface specifications for adding and upgrading peripheral devices to those computers.
Most personal computers ("PCs") designed today still implement peripheral devices based upon interfaces used in the original IBM PC designs of the early 1980s. These implementations have numerous shortcomings that cause both designers and users considerable frustration. Industry leaders are attempting to solve this incompatibility issue in favor of more platform-independent standards.
Background: Universal Serial Bus ("USB")
USB is a peripheral bus specification developed by PC and telecom industry leaders that brings the Plug-and-Play ("PnP") features of many computer peripherals to the outside of the computer chassis, eliminating the need to install cards into dedicated computer slots and reconfigure the system. PCs equipped with USB and PnP allow computer peripherals to be automatically configured as soon as they are physically attached--without the need to reboot or run setup utilities ("hot pluggable"). The resource constraints related to IO address space, IRQ lines, and DMA channels no longer exist with the USB implementation. USB also allows multiple devices--up to 127--to run simultaneously on a computer, with peripherals such as monitors and keyboards acting as additional plug-in sites, or hubs. USB is a medium-bandwidth serial bus architecture supporting from 1 to 12 megabits-per-second data transfer speeds. A more detailed discussion of the USB architecture can be found in: Don Anderson, UNIVERSAL SERIAL BUS SYSTEM ARCHITECTURE, MindShare, Inc. (1997), which is hereby incorporated by reference.
Background: IEEE 1394 High-Speed Serial Bus
The IEEE 1394 Serial Bus standard describes, among other things, a high-bandwidth serial bus architecture scaleable to gigabits-per-second transfer rates. Originally designed to replace parallel SCSI in computer applications, IEEE 1394 provides the means to transmit and receive digital data using low-cost, light-weight serial cable. Although IEEE 1394 is a bus with nodes that arbitrate for access, it also resembles a network in that it is divided into three protocol layers: the physical layer ("PHY"), the link layer ("LINK"), and the transaction layer. The PHY layer is implemented in hardware, and provides the differential drivers and receivers that send and receive data through the serial cables and connections. A PHY chip provides the interface to the physical cable and/or bus. (For example, IBM manufactures a three-port transceiver, the IBM21S750PFC, which implements the physical layer protocol interface to the serial cable.) When the connection is obtained, the PHY layer receives parallel data from the link layer, and serializes and transmits the data through the cable or bus. The LINK layer provides the interface from the PHY layer to the transaction layer. It sends and receives data by forming it into packets, adding headers, and generating and checking cyclic redundancy checks (a transmission error detection scheme). The transaction layer provides a complete request-response protocol to perform the bus transactions (the operations of read, write, and lock). A more detailed discussion of the IEEE 1394 architecture can be found in: 1394-1995 IEEE STANDARD FOR A HIGH-PERFORMANCE SERIAL BUS, IEEE Computer Society (1996); and in D. Anderson, FIREWIRE SYSTEM ARCHITECTURE/IEEE 1394 (1998); both of which are hereby incorporated by reference.
Background: ACPI Specification
"ACPI" (Advanced Configuration and Power Interface) is an interface specification developed by Microsoft, Intel, and Toshiba, for the purpose of defining a standardized mechanism for providing power management functions to the operating system ("OS"). The ACPI specification is part of the OnNow Initiative, which is directed toward PCs being "always on". The ACPI interface specification defines a standard way for the system board to describe its device configuration and power control hardware interface to the OS, and application software.
Background: Device Bay Specification
The Device Bay architecture is a next-generation industry specification that defines a mechanism for easily adding and upgrading PC peripheral devices without opening the computer chassis. The broad capabilities that Device Bay provides for manageability, security, and support for a wide range of peripherals means that the technologies apply to a broad range of PC categories. These applications include business and consumer desktops and portables, small form-factor PCs, home-theater technology, consumer electronics, and PC peripherals. Possible uses of Device Bay include allowing OEMs, retailers, and end-users to easily add the appropriate peripherals to support specific application needs. For example, a CD-R drive (CD with writable media) could be added to provide a large storage medium for digital imaging or audio authoring, a DVD-ROM (Digital Video Disk-ROM) could be added to enable DVD-Video playback, or a smart card reader could be added for secure online banking or shopping. Additionally, hot-swapping capabilities provide for exchanging hard drives during drive failures, or between platforms, mobile or desktop, while the system is powered.
The Device Bay specification defines characteristics to enable compatibility and interoperability between any Device Bay peripheral and any Device Bay-enabled system bay. These characteristics include, among other things, mechanical form factors, power and thermal dissipation criteria, interfaces for USB and IEEE 1394 buses included within the Device Bay interface, connectors, registers for interfacing to ACPI architectures, and software interfaces.
The Device Bay architecture requires, among other components, the presence of a Device Bay Controller ("DBC"). The DBC may be implemented either as an ACPI-based motherboard-resident device or as a USB-based device. If employed as a USB-based device, the DBC may be either on the motherboard or external to the motherboard, such as in a docking station or even in a completely remote Device Bay tower. The Device Bay specification requires an association between the DBC, the 1394 ports, and USB ports connected to Device Bay sockets, and also requires that this association be deterministic. Because of the requirement for this association, some restrictions are placed on the architecture:
1. A system may support any number and combination of ACPI-based or USB-based DBCs. A motherboard-resident DBC may be either ACPI-based or USB-based. A DBC that is not on the motherboard is most easily implemented as a USB-based DBC. (In the earlier version 0.81 of the Device Bay specification, it was mandatory that it be implemented as a USB-based device.) PA0 2. For an ACPI-based DBC: PA0 3. For a USB-based DBC:
a. The USB port associated with each Device Bay socket is specified in the ACPI Name Space, hence there are no restrictions on how USB Host Controller or Hub Controller ports may be connected to Device Bay sockets. PA1 b. A system may support any number and combination of ACPI-based DBCs. PA1 a. USB ports associated with Device Bay sockets are required to be wholly contained within the USB Host Controller or Hub Controller to which the DBC is connected; the connection of the Device Bay socket to USB port is specified in the DBC Bay Port Mapping Register. PA1 b. The 1394 PHY associated with Device Bay sockets is identified by the detection of a DBC connected to its PHY/Link interface. The 1394 ports are required to be contained within that single PHY; the connection of Device Bay socket to PHY port is specified in the DBC Bay Port Mapping Register. The system design is not otherwise restricted.
A particular problem faced by those working within the Device Bay specification is that the Device Bay architecture provides very little flexibility in design. The sole design for a remote (e.g. Remote Device Bay Tower) Device Bay implementation is costly, in terms both of component cost and of circuit board (real estate) cost.
Since a docking station does not have a motherboard (a motherboard is typically understood to contain the main CPU of the host computer), a docking station (as a remote non-motherboard device) may implement a USB-based DBC.
Background: GUID Determination Using a DBC
A "standard" (i.e. Device Bay-compliant) USB-based Device Bay Controller ("DBC") is principally required to: (1) support the functions of a DBC; (2) do so as a USB device; and (3) provide an interface to the 1394 PHY connection in use by Device Bay devices. The purpose of this last interface requirement is to provide a way to obtain the 1394 Global Unique ID ("GUID") corresponding to that 1394 PHY connection. (The GUID is a unique 64-bit vendor identifier.) Normally, the 1394 GUID is determined via a transaction that takes place (across the USB bus) between the host DBC driver software and the USB-based DBC (reading a DBC register to obtain the 1394 GUID).
Architecture with 1394 PHY/Link Emulation in Software
This application discloses a method to minimize the costs imposed by the current Device Bay restrictions, and specifically by the requirements for a USB-based Device Bay controller. Since the USB-based DBC and the 1394 PHY connection are both being designed into the docking station as "permanent" components, the GUID of the 1394 PHY connection is known, and can simply be provided from software. Therefore, the circuitry (and its 14 signal lines) which provides the PHY/Link interface to the DBC can be eliminated, by emulating this device in software. The PHY chips and the 1394 Link Controllers ("Links") are normally discrete devices to be introduced into host systems as adapter card products; but whether discrete or integrated with other functions, this emulation saves money by eliminating a hardware interface.
Additional software components are provided to compensate for the elimination of the PHY/Link interface between the USB-based DBC and the 1394 PHY. By inserting a proprietary "filter driver" into the USB driver stack, it becomes possible to monitor USB communications. After inserting a notebook computer into the docking station, the operating system will detect the presence of the DBC (as a USB device). When the operating system thereafter sends a query to the DBC, to get the GUID of the 1394 bus interface, this query is intercepted by the added filter driver, and the correct GUID is returned without sending the query through the DBC.
A major advantage of this solution is to provide a more cost effective implementation of Device Bay support for the next generation docking station.
A further advantage of the disclosed architecture is that off-the-shelf chips can be used for the DBC and for the 1394 PHY interface chip. The present application teaches that the additional hardware interface from the DBC to the 1394 link can be eliminated, even in a USB device bay controller system, simply by emulating in software the query response which is the primary function of this hardware interface. Thus, the device bay controller can still be an off-the-shelf part, and the 1394 PHY interface can also be another off-the-shelf part, and the two do not have to be specified as a set, i.e., they can be chosen independently.